A virtual machine (VM) is a software implementation of a physical computer. Computer programs designed to execute on the physical machine execute in a similar way when executed on a VM. In some cases, a VM provides a complete system platform to support a full operating system (OS). A physical machine can be shared between users using different VMs, each running a different OS.
Modern processor architectures have enabled virtualization techniques that allow multiple operating systems and VMs to run on a single physical machine. These techniques use a hypervisor layer that runs directly on the physical hardware and mediates accesses to physical hardware by providing a virtual hardware layer to the operating systems running in each virtual machine. The hypervisor can operate on the physical machine in conjunction with a “native VM.” Alternatively, the hypervisor can operate within an operating system running on the physical machine, in conjunction with a “hosted VM” operating at a higher software level. A given hypervisor will exist to service many VMs on a single system. An example of a hypervisor is IBM® Power Series® hypervisor (PHYP).
Examples of VM technology are:                IBM® Power Series logical partitions (LPARs).        Linux® Kernel-Based Virtual Machine (KVM), which allows one or more Linux® or Microsoft® Windows® virtual machines to be run on top of an underlying Linux® that runs KVM.        Xen, which allows a guest (virtualized) Linux® to be run on top of Linux®.        Parallels, which allows Linux® and Windows® on top of Mac OS X.        VMWare which allows Linux® and Windows® systems on top of Mac OS X, Windows® and Linux® systems. IBM and Power Series are trademarks of International Business Machines Corporation. Linux is a registered trademark of Linus Torvalds. Microsoft and Windows are trademarks of Microsoft Corporation.        
In a distributed or “cloud” environment it is possible for VMs to “migrate” between physical systems to facilitate, for example, load balancing and maintenance. Various mechanisms presently allow this to happen in a manner that is transparent to the VM. In certain cases this is undesirable—an example being when the owner of the cloud is not the owner of the VM and so does not have authority to perform migrations. Such situations are common in cloud environments, where VM owners allow a separate cloud provider to host their machine. The VM owner may place restrictions on the VM's ability to migrate around the cloud as part of the service agreement—for example, the VM may not leave the country due to export regulations. Certain hosts may be unsuitable targets for the migration of a VM (e.g., security issues), but implementing control of the system using this information from a central position is unmanageably complex.
The migration restrictions upon each VM in the cloud are tracked from a managing component, and may in fact be too complex, arbitrary or dynamic to calculate outside of the VM itself. In addition, there may be a requirement to migrate a VM from one server to a server of a server pool that satisfies the most criteria.
“Virtual machine migration by respecting the security policies”, Kumar, P, priorartdatabase.com/IPCOM/000177039 (Electronic Publication: Dec. 4, 2008) proposes that security policies for any VM be made available as a bit array policy string included as part of the VM description file. A decision can then be made on a VM migration on whether the VM security policy is met. A static VM description file comprises a bit mask of network security policies required for any hosting system. A VM may not be migrated to a host unless the host provides those features. Hosting systems may be configured to allow modification of their network security policies to accommodate the requirements of incoming migrated VMs. However, migration rules are often far too complex to be computed ahead of time and thus be made static. Further, bit-mask implementation of network protocols and ports to represent such complex rules is difficult.